home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0841.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  5.2 KB  |  148 lines
  1. In <9304061648.AA02068@www3.cern.ch> Tim says
  2.  
  3. > There have been a lot of improvements proposed for HTML.
  4.  
  5. >         - Various forms of includion of graphics
  6. >         - Tables
  7. >         - Forms
  8.  
  9. > I think we should get some concrete proposals for an HTML2 out
  10. > onto this list.  This would bring us closer to a DTD for the
  11. > new thing, which would allow everyone to go out and
  12. > implement it.
  13.  
  14. Glad to hear you say it!
  15.  
  16. > The new format should of course be a superset of HTML.  The first
  17. > thing it should include is indefinite nesting of constructs
  18. > which is not allowed in HTML.
  19.  
  20. Some guidelines would be useful here, e.g. can you nest OL or UL in the
  21. DT glossary text in a DL list, or what about OL within UL within a DL list? 
  22. What level of nesting should browsers aim to show effectively?
  23.  
  24. For formal presentation as an elective Internet standard we should aim to
  25. be as precise as possible, e.g. via accurate DTD's and a range of examples.
  26. I there enclose a DTD fragment with my proposal for forms.
  27.  
  28. > To kick off the discussion, I propose for the forms part the
  29. > following
  30.  
  31. > FIELDS
  32. > ======
  33. > <FIELD NAME="f1" FIELDTYPE=TEXT MAXLEN=40>     </FIELD>
  34.  
  35. Tim, er did you receive my message with a detailed suggestion for forms?
  36.  
  37. My practical experience with building hypertext/forms based interfaces
  38. for sales staff etc. has shown the value of:
  39.  
  40.     o   to be able to freely embed fields in other
  41.         textural or graphical backgrounds
  42.  
  43.     o   the need for fields with constrained types
  44.         e.g. dates, booleans, integer ranges, free text, ...
  45.  
  46.     o   the need to initialise fields with default values
  47.  
  48.     o   the ability to highlight fields as being in error
  49.  
  50.     o   the ability to disable the field to prevent further change
  51.  
  52.     o   the need for one-from-many AND many-from-many menus
  53.  
  54.     o   giving authors control over the realisation of such menus
  55.         e.g. radio buttons, drop down, and permanently visible lists
  56.  
  57. Fields showing derived values, (e.g. a total figure in an expenses claim),
  58. and arbitrary constraints between different fields can be handled by the
  59. server. In this way you avoid can the need for a scripting language.
  60.  
  61. If the user sets a field to an incorrect value, the ability to highlight
  62. the field makes it practical to draw the user's attention to that field
  63. with the implication that its value should be changed. An accompanying
  64. error message can be given as part of the surrounding text.
  65.  
  66. Similarly, it is often the case that given certain settings of fields, that
  67. other fields cannot be changed. To make this obvious you should change the
  68. appearence of these fields. In my browser, I show fields with a darker colour
  69. when they accept input and the lighter window background colour when they are
  70. read-only. Clicking the mouse over a read-only field has no effect.
  71.  
  72. As an author I want control over how a selection menu appears. When there are
  73. few choices, radio buttons or lists work well. When there are lots of
  74. selection fields it is strongly desirable to be able to use drop-down
  75. selections, which appear in the body of the form as a button and a box
  76. showing the currently selected value(s) for that field. Clicking on the
  77. button causes the list of possible choices to appear, with the current
  78. selection highlighted in some way.
  79.  
  80. Essentially we need two tags, one for input fields and one for selections.
  81. These should be able to be placed freely with other HTML tags, so that you
  82. could embed fields in a preformatted text if you need tight control over
  83. the appearence. You could also put input and (dropdown) selection fields in
  84. glossary lists.
  85.  
  86.  
  87. Input Fields:
  88. ============
  89.  
  90. These fields have the following attributes:
  91.  
  92.     o   field name - used to identify the field's value to the server
  93.  
  94.     o   field type - boolean, text, date, uri, integer, float
  95.  
  96.     o   field width (optional) giving maximum length of field value
  97.  
  98.     o   field status (optional) ok (the default), in error, read-only
  99.  
  100.     o   initial value (optional)
  101.  
  102.  
  103. Selection Fields:
  104. ================
  105.  
  106. These fields have the following attributes:
  107.  
  108.     o   field name - used to identify the field's value to the server
  109.  
  110.     o   field type - one-from-many or many-from-many
  111.  
  112.     o   field appearence (optional) radio, list, drop-down
  113.  
  114.     o   field status (optional) ok (the default), in error, read-only
  115.  
  116. The field appearence is a hint to the browser of how the author intends the
  117. field to be displayed. For a drop-down field it would also be desirable to
  118. be able to suggest the maximum size for displaying current selections,
  119. particularly with many-from-many fields.
  120.  
  121. The set of possible choices can be specified as Tim points out with the
  122. <LI> tag without the need for a new tag.
  123.  
  124. Here is my suggested DTD for the <input> and <select> tags. I prefer
  125. these names as they seem more verb-like and appropriate than <field>
  126. and <radio>.
  127.  
  128. <!-- INPUT tag
  129.  
  130.     o   The field name and type are required.
  131.  
  132.     o   The width, status and value attributes are optional.
  133.  
  134.     o   Boolean fields have values "yes" or "no"
  135.  
  136.     o   Date fields have values matching:
  137.  
  138.             "19th January 1992"
  139.             "19 Jan 92"
  140.             "19 Jan 92"
  141.             "19/1/92"   with '/' or '-' as separators
  142.             "1/19/92"
  143.  
  144.     o   URL fields have values corresponding to existing standards
  145.         for universal resource locators
  146.  
  147.     o   values should be enclosed on "quotes"
  148.